Summary

• Closes [BUG] Trace files never get cleaned up #951. config.data_retention only purged rows from collect.* tables; the .trc files written by collect.trace_management_collector were never deleted and accumulated forever in the SQL Server error log directory (reporter saw ~7 GB / 106 files going back 2 months).
• Adds a trace-file cleanup block to config.data_retention that reads retention_days from config.collection_schedule for trace_management_collector (30-day fallback), derives the error log directory via SERVERPROPERTY('ErrorLogFileName') (same logic the collector uses), and calls master.dbo.xp_delete_file to delete Monitor_LongQueries_*.trc files older than the cutoff. The active trace file stays locked open so it survives.
• Pre-checks via xp_dirtree (cross-version, SQL 2016+) to skip xp_delete_file when no matching files exist — suppresses the noisy "Msg 22049" output xp_delete_file prints on empty matches. TRY/CATCH also carves out 22049 as benign on older SQL versions where it surfaces as a catchable error.
• Honors the existing @retention_days override semantics: NULL reads from config.collection_schedule, non-NULL uses the flat value (matches table-cleanup behavior directly above in the proc).
• Logs a separate config.collection_log row so trace cleanup is independently auditable from table cleanup.

Test plan

• Install script applies cleanly via sqlcmd -i install/43_data_retention.sql on SQL 2022
• EXECUTE config.data_retention @debug = 1 runs end-to-end without aborting, logs SUCCESS for trace cleanup with pattern + cutoff visible
• Pre-check via xp_dirtree correctly counts matching Monitor_LongQueries_*.trc files
• Verify against the reporter's SQL 2019 CU32 environment (or any 2019 instance with accumulated .trc files) that old files are actually deleted
• Confirm Agent job step output stays clean across a few retention cycles (no Msg 22049 spam)
• Confirm active trace file is preserved (not deleted while sys.traces shows it running)

🤖 Generated with Claude Code